In mobile networks, such as a 3GPP (Third Generation Partnership Project) cellular network, various types of cellular devices may be used. For example, Machine Type Communication (MTC) cellular devices may be used in addition to conventional types of cellular devices, in the following also termed as user equipment (UE), such as mobile phones, smartphones, data modems, mobile computers, or the like. MTC cellular devices typically transmit and receive only small amounts of data, which may occur more or less infrequently, e.g., once per week to once per minute. MTC cellular devices are typically assumed to be autonomous sensor devices, alarm devices, actuator devices, remote control devices, or the like, which communicate with an application server, rather than being used for communication by a human user. Hence, this type of communication may also be referred to as machine-to-machine (M2M) communication and the devices may be denoted machine devices (MDs). The application server may be within or outside the mobile network.
Considering the above, MTC cellular devices are typically characterized by a modest bit rate and sparse communication. MTC cellular devices may therefore be implemented with low-performance data transmission capabilities. Further, MTC cellular devices typically need to be very energy efficient, since external power supplies may not be available and/or it may be practically or economically not feasible to frequently replace or recharge their batteries.
A known way of energy saving in a UE, which may also be applied to MTC cellular devices, is to use Discontinuous Reception (DRX). By means of DRX, a UE can enter an energy efficient sleep mode when no data transmission is needed. In the sleep mode, receiver circuitry of the UE may be turned off. DRX can be applied in connected mode, but also in idle mode, in which the UE only receives paging information on certain paging occasions. The latter scenario may also be referred to as paging DRX or idle DRX. In this connection, also “long DRX” cycles with sleep periods in the order of seconds or even minutes are considered for improving energy efficiency of MTC cellular devices.
In the long DRX solution, Paging Indication (PI) messages may be sent less often than in regular scenarios. This allows the MTC cellular device to stay remain in the sleep mode for a longer time because it needs to receive the PI messages as often as in regular scenarios. The DRX cycle length may thus correspond to the time between two subsequent PI messages. If there is incoming data for the MTC cellular device, it is paged using the PI message and when the MTC cellular device responds to the PI message, a data communication channel, or Packet Data Protocol (PDP) context, is created and used to send the data to the MTC cellular device.
In some application scenarios, there may be an application-specific requirement on how frequently a device needs to be able to receive data. This requirement may also be known to the cellular network. For example, such information may be preconfigured in the cellular network or in subscription information of the MTC cellular device. Further, the application server could dynamically indicate such information to the cellular network. Still further, the MTC cellular device could indicate such information to the cellular network when setting up a PDP context. The cellular network may then use this information to set the largest supported DRX cycle length which allows for complying with the application-specific requirement. This allows for optimized benefit from energy saving due to DRX.
Accordingly, some information related to the maximum utilized DRX cycle length may be available on the application level, in particular in the application server. However, knowledge of a maximum DRX cycle length does not allow for determining when in detail the MTC cellular device will be able to receive data. This is particularly relevant for long DRX cycles in which the sleep period is significantly longer than the active period in which the MTC device can receive data. This may adversely affect interaction between the MTC cellular device and the application server.
For example, the MTC cellular device could be a display device which gets updates of a value to be displayed, e.g., a measured temperature, from the application server. Such display device could be implemented in a couple of different ways. In one implementation, the display device could be configured as a “normally-off” device that occasionally wakes up and connects to the cellular network to receive a value update, and then disconnects from the cellular network, leaving just the display on to show the updated value. However, such mode of operation may cause significant power consumption, e.g., for regular attach/detach signaling, requesting a value update even when the value is not changed, or the like. Further, showing of a value change on the display update may be delayed due to waiting for transmission of the value update in the next occasion of waking up. In another implementation, a long DRX cycle may be applied for the display device. By suitably adjusting the DRX cycle length, a trade-off between power consumption and real-time updating of the displayed value may be obtained. However, also in the latter case there may be undesired delays due to the DRX cycle not being synchronized with the sending of the value update, e.g., if the application server sends the value update just after the sleep period of the DRX cycle has begun. Assuming an exemplary DRX cycle length of one minute, the application server could send the value update one second after beginning of the sleep period, and the value update would be received by the display device only at the beginning of the next active period of the DRX cycle, e.g., 59 seconds later. This requires long buffering of the value update in the cellular network and may even involve the risk of the value update not being successfully received by the display device due to insufficient buffering capacity. Further, the displayed value may be outdated already when the value update is received.
Accordingly, it may desirable to provide information allowing for synchronization with the active period of the DRX cycle to the application level, in particular to the sender. However, such information is not available in many practical application scenarios, e.g., due to the lack of suitable interfaces between the application layer and the lower layers implementing the DRX functionalities.
Accordingly, there is a need for a solution which allows for efficiently determining information about a DRX cycle utilized by a certain cellular device.